В этом коротеньком посте приведем список горячих клавиш, которые помогут вам управляться с vSphere Web Client.

• Ctrl + Alt + 1 = Перейти в представление Home
• Ctrl + Alt + 2 = Перейти в представление vCenter Home
• Ctrl + Alt + 3 = Перейти в представление Hosts & Clusters
• Ctrl + Alt + 4 = Перейти в представление VM & Templates
• Ctrl + Alt + 5 = Перейти в представление Datastores
• Ctrl +Alt + 6 = Перейти в представление Networks
• Ctrl + Alt + S = Поместить фокус в поле поиска (Search)

Одна из самых популярных статей на VM Guru - это статья про типы дисков виртуальных машин на платформе VMware vSphere. Там рассказано про все имеющиеся виды виртуальных дисков, среди которых можно выделить три основных:

• Lazy zeroed thick disks - все пространство диска выделяется в момент создания, при этом блоки не очищаются от данных, которые находились там ранее. Но при первом обращении ВМ к этому блоку он обнуляется.
• Eager zeroed thick disks - все пространство такого диска выделяется в момент создания, при этом блоки очищаются от данных, которые находились там ранее. Далее происходит обычная работа с блоками без очистки.
• Thin disks ("тонкие диски") - эти диски создаются минимального размера и растут по мере их наполнения данными до выделенного объема. При выделении нового блока - он предварительно очищается. Эти диски экономят пространство на массиве, так как не забивают его нулями и не требуют аллокации заданного объема.

Между администраторами VMware vSphere очень часто возникает дискуссия: диски какого типа нужно создавать, особенно если дело касается высоких нагрузок ВМ на дисковую подсистему? Сейчас это становится актуальным и для флэш-массивов, которые начинают появляться в организациях различного масштаба и предназначены как раз для высоких нагрузок ВМ на диски.

Специально для таких пользователей компания VMware провела тесты для последовательных и случайных операций при работе с виртуальными дисками различного типа, используя для этого дисковые массивы с SSD-накопителями.

Результаты оказались интересны - диски типа Thin и Lazy zeroed серьезно уступают в производительности дискам Eager zeroed, когда дело касается нагрузок случайного типа.

Использованная тестовая конфигурация:

• Сервер Dell R910 с 40 ядрами и 256 ГБ оперативной памяти.
• Дисковый массив Pure FA-420 FlashArray с двумя полками, на которых 44 флэш-диска по 238 ГБ каждый (суммарно 8.2 ТБ полезной емкости).
• Виртуальная машина Windows 2008 R2 Virtual Machine следующей конфигурации: 4 vCPU, 8 GB RAM, 40 GB OS/Boot Disk, 500 GB Data Disk.
• Инициатор SW iSCSI для карточки 10 Gb.

Таблица результатов тестов, сделанных с помощью IOMETER для различных размеров блоков:

Из таблицы видно, что все диски на последовательных нагрузках показывают примерно одинаковый результат, а вот на Random-нагрузках уже совершенно другая картина. Все это более наглядно можно увидеть графиков, где диски Thin и Lazy zeroed существенно проседают по производительности:

Вывод - не все йогурты одинаково полезны. Для высокопроизводительных нагрузок желательно использовать диски типа Eager zeroed - хуже точно не будет. Единственный их минус - требуется существенное время на их создание, поскольку происходит обнуление блоков. Но если ваш дисковый массив поддерживает примитивы VAAI, то много времени не понадобится: например, в том же тесте диск Eager zeroed размером 500 ГБ создался менее чем за одну минуту.

Как вы знаете, совсем недавно была выпущена новая версия продукта StarWind Virtual SAN, предназначенного для создания отказоустойчивых хранилищ на базе iSCSI для виртуальных машин VMware vSphere и Microsoft Hyper-V. О новых возможностях этого продукта мы уже рассказывали тут, кроме того, скоро мы расскажем о нововведениях более детально.

В этом же посте мы приглашаем вас на вебинары StarWind, посвященные обновленной версии StarWind Virtual SAN V8. На вебинаре будет присутствовать Макс Коломейцев, а значит сможет ответить на вопросы на русском языке:

Webinar: New Approaches in Hardware-less SAN Storage for Remote & Branch Offices

Вебинар пройдет 3 июня, в 22-00 по московскому времени. Вместо того, чтобы выпить пива, приходим на вебинар посвященный построению инфраструктуры хранения в небольших компаниях и филиалах, где нужно экономить средства на покупку оборудования и лицензий. С продуктом StarWind это делается очень просто.

Регистрация на вебинар

--------------------------------------------------------------------

Live Webinar: Show Me The Storage!

Вебинар пройдет 5 июня, также в 22-00 по московскому времени. Этот вебинар будет как бы продолжением предыдущего, но здесь будут уже затронуты технические аспекты технологии StarWind, позволяющей создать надежную инфраструктуру хранения. Будет рассказано о технологиях репликации по LAN и WAN, а также расскажут о том, почему StarWind является лидирующей на сегодняшний день технологией на рынке iSCSI-хранилищ.

Регистрация на вебинар

Приходите, будет интересно!

Мы уже затрагивали тему новой версии продукта Veeam Backup and Replication v8, предназначенного для резервного копирования и репликации виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Напомним, что в восьмой версии продукта будет поддержка работы с массивами NetApp, а также было анонсировано средство для восстановления объектов каталога - Veeam Explorer for Active Directory.

На днях же компания Veeam официально объявила о скором выпуске Backup and Replication v8 и пакета продуктов Veeam Availability Suite. Этому на сайте Veeam посвящена отдельная страница: http://go.veeam.com/availability-suite-v8.

Традиционно Veeam Availability Suite v8 будет представлять собой набор продуктов Veeam Backup & Replication v8 плюс решение для мониторинга и управления изменениями Veeam ONE.

Перечислим основные новые функции пакета:

• Новые средства для восстановления объектов Veeam Explorer for Exchange, SharePoint, SQL (впервые появится в v8), AD (подробнее - тут).
• Новый продукт Veeam Explorer for Storage Snapshots (HP и NetApp), позволяющий делать резервные копии из снапшотов хранилищ и быстро восстанавливать ВМ из этих копий.
• Поддержка EMC Data Domain Boost - появится возможность интеграции с этим механизмом EMC, что сократит окна резервного копирования за счет ускорения создания синтетических полных бэкапов до 10 раз.
• Новая технология End-to-End Encryption - теперь передаваемые данные при резервном копировании шифруются (AES 256), и даже если вы потеряете пароль, то все равно сможете восстановить виртуальные машин их резервных копий.
• Улучшения репликации - теперь репликация по WAN работает быстрее, появится возможность репликации из бэкапа (для очень удаленных площадок) и появится возможность переключения на резервную площадку в один клик.
• Это еще не все, ожидайте позднее полный список возможностей.

Больше деталей можно узнать в пресс-релизе Veeam. Выход новой версии Veeam Backup & Replication v8 и Veeam Availability Suite v8 ожидается в конце августа-начале сентября этого года. Предполагаемые цены в США - $1 100 за Standard Edition, $1 550 за издание Enterprise и $2 300 за Enterprise Plus Edition.

Напомним, что обо всем этом и многом другом компания Veeam расскажет на первой своей собственной конференции VeeamON, которая продет c 5 по 9 октября в Лас-Вегасе.

P.S. Я все еще жду от вас бесплатный билет, коллеги!)

Не так давно мы писали о доступности бета-версии средства VMware Log Insight 2.0, предназначенного для автоматизированного управления файлами журналов, а также сбора различных данных, их анализа и поиска. Вчера компания VMware анонсировала релизную версию VMware Log Insight 2.0.

Приведем здесь полный список новых возможностей решения Log Insight 2.0:

1. Улучшения производительности масштабируемости:

• VMware заявляет, что Log Insight работает в 6 раз быстрее конкурента - продукта Splunk.
• До 8 раз увеличена скорость сбора данных и до 6 раз - скорость выполнения запросов.
• До 2 ТБ анализируемых данных на узел.
• До 30% улучшения производительности отдельных узлов.
• Возможность масштабирования до 6 узлов при анализе данных.

2. Высокая доступность:

• Улучшения скорости обмена до 5-10 раз при работе в режиме Cluster mode.
• Нет единой точки отказа - при запросах можно использовать внешний балансировщик, перенаправляющий запросы к узлам. Появилась интеграция с решением vCenter Operations Management Suite.
• Единый интерфейс для работы со всеми данными узлов.

3. Проактивная аналитика:

• Обучаемая система типов событий и распознавания схем данных с интеллектуальной группировкой (близкие сообщения хранятся рядом).
• "Умные поля" в отчетах (распознается тип данных в поле).
• Сбор данных с таких продуктов VMware, как NSX, vCloud Automation Center, Horizon View.

4. Улучшенные дэшборды и графический интерфейс:

• Интерфейс на основе HTML 5.
• Простое добавление фильтров на лету.
• Возможность взаимодействия между разными виджетами одного дэшборда.
• Теперь работа с диаграммами стала намного удобнее (новые виды диаграмм, можно прятать колонки, можно добавлять чарты на дэшборд).

5. Поддержка RESTful API при работе с логами.

6. Улучшенные механизмы мониторинга собственного состояния.

7. Агент для сбора логов Windows:

• Перенаправляет Windows event logs.
• Мониторит изменения файлов журнала.
• Функции централизованной отчетности и управления логами.
• Потребляет мало ресурсов (до 5% CPU и 100-200 МБ оперативной памяти).
• Поддерживает автоматическую ротацию логов.

Кроме того, в скором времени будут доступны дополнительные контент-паки для следующих продуктов:

• Brocade SAN Content Pack – мониторит события с FC-коммутаторов Brocade, генерирует алерты
• Microsoft Active Directory Content Pack
• Microsoft Exchange Content Pack
• Microsoft Windows Content Pack

Дефолтный контент-пак для VMware vSphere содержит следующие представления:

• General – Overview
• General – Inventory
• General – Security
• vCenter – Alarms
• vCenter – Tasks
• ESXi
• DRS
• HA
• Networking
• Storage – Overview
• Storage – SCSI latency/errors
• Storage SCSI Sense Codes
• Storage – NFS
• Virtual Machine

Теперь лицензирование VMware Log Insight построено не на базе объема обрабатываемых данных, а на базе анализируемых систем (стоит это $200 за систему). Можно также купить лицензию на 1 физический процессор (CPU) сервера Log Insight.

Сам продукт VMware Log Insight 2.0 будет доступен для загрузки во втором квартале этого года. Более подробно о продукте можно узнать тут, а контент-паки можно загрузить отсюда.

Некоторое время назад мы писали о том, как запускать вложенный гипервизор и виртуальные машины (nested VMs) на платформе VMware vSphere. В статье по ссылке показано, что можно запустить как вложенную платформу VMware ESXi, так и вложенный сервер с ролью Hyper-V, при этом можно запускать виртуальные машины в этих ВМ.

А как обстоят дела с вложением Hyper-V в Hyper-V? При попытке поставить роль Hyper-V в виртуальной машине Windows Server 2012 R2 вы получите вот такие сообщения об ошибках:

Hyper-V cannot be installed: A hypervisor is already running.

Если попробуем включить роль через PowerShell получим аналогичную ошибку:

Но саму роль Hyper-V в виртуальной машине на Windows Server включить можно. Делается это средствами утилиты по обслуживанию образов DISM.exe. Если вы используете Windows 8 как гипервизор, то потребуется скачать еще и пакет Windows Assessment and Deployment Kit (ADK) for Windows 8.

Выполняем следующие команды в консоли:

DISM /Online /Enable-Feature /FeatureName: Microsoft-Hyper-V
DISM /Online /Enable-Feature /FeatureName: Microsoft-Hyper-V-Management-Clients

Далее роль встанет, и можно запустить консоль управления виртуальными машинами.

Но при попытке запустить виртуальную машину будет выведена ошибка:

VM failed to start. Failed to start the virtual machine because one of the Hyper-V components is not running.

Для этой проблемы пока решения нет. Виртуальную машину вы не сможете запустить на Hyper-V никак. Хотя на VMware vSphere 5.x все будет прекрасно работать.

Здесь же вы только сможете сделать такие вложенные ВМ узлами Failover Cluster для целей тестирования или снятия скриншотов:

Все это происходит из-за того, что Microsoft не хочет предоставлять виртуальным машинам средства эмуляции техник аппаратной виртуализации Intel VT и AMD-V, хотя многие пользователи и спрашивают об этом. По мнению сотрудников Microsoft, которых можно встретить на форумах technet, "это не нужно".

От администратов VMware vSphere часто приходится слышать о том, что есть категория пользователей, которой хотелось бы предоставить доступ к отдельным задачам по работе с виртуальной инфраструктурой, при этом не давая доступ к средствам управления VMware vSphere Client или Web Client. Например, это может оказаться необходимо сетевым администраторам или администраторам хранилищ. Особенно эта задача актуальна тогда, когда реализация необходимой функции состоит из нескольких шагов, некоторые из которых нельзя сделать в графическом интерфейсе vSphere Client.

В этом случае проблема решается средствами интерфейса PowerCLI / PowerShell, а вот недавно обновившаяся утилита с VMware Labs - Web Commander 3.0 - позволяет опубликовать командлеты PowerShell через веб-интерфейс, доступ к которому можно предоставить пользователям.

Что нового появилось именно в третьей версии:

• Новый интерфейс
• Улучшенные контролы
• Улучшенный рабочий процесс
• Новые команды для сервера

Системные требования для установки Web Commander:

• ОС Windows 2008 или 2012
• Установленный Powershell версий 3/4, а также фреймворк vSphere PowerCLI
• Сервер приложений IIS 8
• Установленный PHP 5

Скачать Web Commander можно по этой ссылке, документация по установке доступна здесь.

Интересная новость пришла с конференции EMC World 2014, которая проходила с 5 по 8 мая в Лас-Вегасе. Теперь при построении распределенного ("растянутого") кластера VMware HA/DRS (он называется vSphere Metro Storage Cluster, vMSC) поддерживается задержка RTT (Round Trip Time) в канале до 10 миллисекунд. Для такого варианта использования сертифицировано решение VPLEX Geosynchrony 5.2, начиная с версии VMware vSphere 5.5.

Надо сказать, что технология EMC VPLEX Metro ранее поддерживалась на расстояниях между ЦОД в диапазоне до 100-150 км (иногда несколько более), где возникают задержки (latency) до 5 мс (это связано с тем, что RTT-время пакета в канале нужно умножить на два для FC-кадра, именно два пакета необходимо, чтобы донести операцию записи). Но и 150 км - это вовсе немало. Теперь же это расстояние увеличилось до 300 километров.

Ранее технология vMotion поддерживалась и для latency до 10 мс, а вот механизм отказоустойчивости VMware HA гарантированно работал только для задержек до 5 мс.

При этом сейчас кластер vMSC сертифицирован как для нативного плагина доступа к хранилищам NMP (Native Multi-pathing), так и для плагина PowerPath/VE. Здесь надо обязательно отметить, что данная конфигурация поддерживается только издания VMware vSphere Enterprise Plus.

Более подробная информация о кластерах vMSC приведена в KB 2007545.

В выпущенной еще в прошлом году версии платформы виртуализации VMware vSphere 5.5 компания VMware представила решение App HA, которое выросло из функций  VM Monitoring, средствами которых можно было обнаруживать недоступность отдельной ВМ и перезапускать ее в случае сбоя. Потом эти возможности решили применить и к отдельным приложениям, в результате чего и появилось решение App HA:

Теперь App HA поддерживает некоторое количество приложений, поведением по "лечению" которых можно управлять на базе политик.

В середине апреля было выпущено решение VMware App HA 1.1, в котором появилось несколько новых возможностей:

• Теперь из коробки поддерживается больше приложений: Oracle (10g и 11g), а также PostgreSQL (8.x и 9.x).
• Поддержка любого сервиса: теперь агенты Hyperic можно использовать для любого сервиса в гостевой ОС (старт/стоп сервиса).
• Улучшенная совместимость с разными версиями vSphere - поддерживается как vSphere 5.5, так и 5.1.
• Возможность гибкого редактирования политик App HA, в том числе тех, которые уже назначены различным сервисам.
• Добавлено 6 языков, русского, к сожалению, нет.

Таким образом, решение App HA поддерживает мониторинг следующих приложений в гостевых ОС виртуальных машин:

А вот табличка совместимости App HA с различными компонентами VMware vSphere:

Полезные ссылки:

• Скачать App HA
• Документация
• Release notes
• Руководство по установке
• Гайд по совместимости

Компания VMware обновило свое бесплатное решение для миграции физических и виртуальных серверов на платформу VMware vSphere - VMware Converter Standalone 5.5.1. Напомним, что о новых возможностях Converter Standalone 5.5, вышедшего еще в октябре прошлого года, мы уже писали вот тут.

Новых возможностей Converter Standalone 5.5.1 всего две:

• Поддержка кластеров хранилищ VMware VSAN в качестве целевых хранилищ при миграции.
• Поддержка метода аутентификации DSA при конвертации машин с ОС Linux.

Кроме того, было несколько исправлений ошибок, среди которых, например, фикс бага, когда не поддерживалась конвертация Linux-систем, если целевой диск превышал 2 ТБ.

Скачать VMware vCenter Converter Standalone 5.5.1 можно по этой ссылке. Документация доступна тут.

Не так давно мы уже писали про приложение VMware vSphere Mobile Watchlist, которое позволяет мониторить виртуальную инфраструктуру с телефона на Android и iOS / iPhone, а также своевременно обнаруживать и решать проблемы удаленно. Недавно, 21 апреля, это приложение было обновлено - теперь новые версии (1.3) доступны для Android и iOS.

Новые возможности vSphere Mobile Watchlist:

• Добавлена поддержка хостов ESXi для мониторинга и решения проблем (раньше были только виртуальные машины).
• Улучшенное отображение связанных объектов (например, можно вывести все ВМ на хостах, хранящихся на определенном хранилище или в определенной ести), а также их алертов.
• Добавление хостов и виртуальных машин в список отслеживания напрямую из связанных объектов.
• Операции с набором хостов: включение/выключение, сетевые настройки и режим обслуживания (maintenance mode).
• Улучшенный интерфейс и система навигации по экранам.
• Несколько багофиксов.

Интересное обзорное видео продукта от Владана:

Пока возможности продукта слабоваты (например, нет vMotion и прочего), но сам факт того, что он развивается достаточно быстро (первая версия - в феврале), говорит о том, что скоро он будет вполне юзабелен.

Комьюнити по продукту доступно по этой ссылке. В качестве платформы поддерживается VMware vSphere 5 и более поздние версии.

На прошлой неделе компания VMware объявила о запуске нужного сервиса по восстановлению инфраструктуры Disaster Recovery для облачной инфраструктуры vCloud Hybrid Service (vCHS). Напомним, что совсем недавно сервисы vCHS подешевели и стали доступны в Европе.

Анонсированное DR-решение доступно как услуга (RaaS, Recovery-as-a-Servie) для конечных заказчиков, которые могут делать бэкап своего частного облака в инфраструктуру vCHS. При этом для заказа услуги (она доступна на 1,12,24 или 36 месяцев) не требуется быть клиентом vCHS и иметь там свою виртуальную инфраструктуру.

Это очень удобно для тех заказчиков, которые не хотят вкладывать сразу большие деньги в построение полноценной резервной площадки, а пока просто хотят протестировать сервисы катастрофоустойчивости VMware. Ведь в любой момент можно отказаться от использования vCHS, когда будут введены в эксплуатацию собственные резервные мощности.

Новые возможности Disaster Recovery в облаке vCloud Hybrid Service:

• Self-Service disaster recovery Protection - возможность защитить до 500 виртуальных машин с помощью технологии vSphere Replication самостоятельно, прямо из консоли vCenter Server.
• Custom Recovery Point Objectives - возможность настройки политик репликации, которые дают RPO от 15 минут до 24-х часов, в зависимости от характеристик канала связи, объема реплицируемых данных и прочих факторов.
• Industry-Standard Recovery Time Objectives - время восстановления сервиса после сбоя (RTO) гарантировано на уровне 4-х часов (или менее), что подразумевает полное включение резервных копий всех машин на стороне vCHS.
• Automated Failover Testing, Planned Migrations and Recovery - встроенные возможности (преднастроенные workflows), позволяющие проводить тестирование аварийного восстановления, live-восстановление продуктивной ВМ в среду vCHS, а также проводить запланированные миграции в облако VMware.
• Elastic Cloud Compute and Storage - возможность гибкого изменения требуемых под DR-инфраструктуру ресурсов, что позволяет, например, быстро построить среду под аварийное восстановление инфраструктуры на стороне vCHS в самое ближайшее время.
• Offline Data Seeding - возможность первичной передачи большого объема данных через офлайн-механизм vCloud Connector Offline Data Transfer.
• Private Leased Line Networks - использование выделенных провайдерских сетей (Direct Connect) для возможности аварийного восстановления.
• Flexible Failover Testing - возможность использования различных преконфигуренных сценариев аварийного восстановления.

Для использования сервисов DR в vCHS вам потребуется:

• VMware vSphere 5.1 или выше
• VMware vCenter 5.1 или выше
• Механизм VMware vSphere Replication 5.6
• Подписка VMware vCloud Hybrid Service – Disaster Recovery
• Развернутый виртуальный датацентр (DR-VDC) в инфраструктуре vCloud Hybrid Service
• Достаточное по скорости соединение через интернет с облаком vCHS

Сначала DR vCHS можно купить как Core Service базовой мощности:

А потом уже можно расширять его аддонами (минимальная гранулярность подписки - месяц, что удобно):

Более подробно о возможностях аварийного восстановления своей инфраструктуры в среду vCHS можно почитать в даташите или FAQ.

Пару недель назад мы писали об уязвимости OpenSSL HeartBleed, которая коснулась виртуальной инфраструктуры VMware vSphere, а также других продуктов компании VMware. Напомним, что эта уязвимость позволяла злоумышленнику получить доступ к памяти сервера, где могут храниться логины/пароли и другая информация пользователей.

На прошлой неделе компания VMware выпустила фиксы для этого бага в виде обновлений VMware vSphere 5.5 Update 1a и VMware vSphere 5.5c, подробнее о которых написано в специальной статье KB 2076665.

Но тут, как часто бывает, вышла оказия. Нашелся еще один баг в VMware vSphere 5.5 Update 1 - оказывается, если для этого билда использовать NFS-хранилища, то они периодически отваливаются, то есть переходят в состояние APD (All paths down). Это касается и VSA-хранилищ. В логах при этом наблюдается что-то вроде такого:

2014-04-01T14:35:08.074Z: [APDCorrelator] 9413898746us: [vob.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:35:08.075Z: [APDCorrelator] 9414268686us: [esx.problem.storage.apd.start] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down state.
2014-04-01T14:36:55.274Z: No correlator for vob.vmfs.nfs.server.disconnect
2014-04-01T14:36:55.274Z: [vmfsCorrelator] 9521467867us: [esx.problem.vmfs.nfs.server.disconnect] 192.168.1.1/NFS-DS1 12345678-abcdefg0-0000-000000000000 NFS-DS1
2014-04-01T14:37:28.081Z: [APDCorrelator] 9553899639us: [vob.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.
2014-04-01T14:37:28.081Z: [APDCorrelator] 9554275221us: [esx.problem.storage.apd.timeout] Device or filesystem with identifier [12345678-abcdefg0] has entered the All Paths Down Timeout state after being in the All Paths Down state for 140 seconds. I/Os will now be fast failed.

Решения для этой проблемы пока нет, поэтому рекомендуется просто откатиться на VMware vSphere 5.5 (без Update 1), если вы используете NFS-хранилища или модуль VSA.

Так вот, поэтому vSphere 5.5 Update 1 и просто vSphere 5.5 надо обновлять разными патчами для устранения уязвимости OpenSSL HeartBleed (чтобы на 5.5 не накатилась проблема с APD):

VMware ESXi 5.5, Patch Release ESXi550-201404001
Это патч только для фикса хостов ESXi 5.5 Update 1

VMware ESXi 5.5, Patch Release ESXi550-201404020
А этот патч для фикса хостов разных версий 5.5 за исключением ESXi 5.5 Update 1, а именно:
ESXi 5.5.0 hosts
ESXi 5.5.0 hosts patched with ESXi550-201312101-SG bulletin
ESXi 5.5.0 hosts patched with ESXi550-201312401-BG bulletin
ESXi 5.5.0 hosts patched with ESXi550-201403101-SG bulletin
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131201001s-no-tools image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20131204001-no-tools image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-standard image profile
ESXi 5.5.0 hosts patched with ESXi-5.5.0-20140301001s-no-tools image profile

Для серверов vCenter есть также соответствующие патчи:

• VMware vCenter Server 5.5 U1a
• VCVA 5.5 U1a
• VMware vCenter Server 5.5c
• VCVA 5.5c

VMware рекомендует сначала обновить серверы vCenter, а потом уже обновлять хосты ESXi. Сама процедура обновления описана в KB 2076692.

После обновления, на хостах ESXi надо перегенерить сертификаты и сменить пароли root. Делается это так:

cd /etc/vmware/ssl
/sbin/generate-certificates
chmod +t rui.crt
chmod +t rui.key
passwd root

Ну и надо отметить, что для всех остальных продуктов VMware также вышли фиксы уязвимости OpenSSL HeartBleed. Информация о них доступна по этой ссылке: http://www.vmware.com/security/advisories/VMSA-2014-0004.html.

Еще на прошлой неделе компания VMware выпустила познавательный документ "What’s New in VMware vSphere 5.5 Networking", в котором детально описываются нововведения, которые были сделаны в плане сетевого взаимодействия в VMware vSphere 5.5.

Напомним, что новая версия платформы принесла 5 основных нововведений в категории Networking:

• Улучшения Link Aggregation Control Protocol (LACP) - поддержка большего числа алгоритмов балансировки.
• Traffic Filtering - функции фильтрации трафика.
• Quality of Service Tagging - поддержка тэгирования различных типов трафика в соответствии с уровнем обслуживания, заданным для него на уровне VDS.
• Улучшения SR-IOV - напомним, что поддержка этих функций появилась еще в vSphere 5.1, теперь же процесс настройки этих функций существенно упрощен.
• Host-Level Packet Capture - появилась встроенная утилита для захвата пакетов на уровне хоста.

Собственно об этом всем подробно рассказывается в небольшом документе на 7 страницах, который содержит следующие разделы:

• VMware vSphere Distributed Switch Enhancements
  • Link Aggregation Control Protocol
  • Traffic Filtering
  • Quality of Service Tagging
• Troubleshooting and Performance Enhancements
  • Enhanced Host-Level Packet-Capture Tool
  • 40GB Network Adapter Support
  • Single-Root I/O Virtualization Enhancements

Скачать документ можно по этой ссылке.

Еще в октябре 2012 года компания Microsoft выпустила первую версию своей утилиты Virtual Machine Converter для преобразования виртуальных машин VMware в формат виртуальных дисков VHD на платформе Hyper-V. С тех пор прошло много времени, формат виртуальных дисков Microsoft обновился до VHDX, а платформа виртуализации Hyper-V обновилась до третьей версии.

Поэтому неделю назад Microsoft выпустила Virtual Machine Converter 2.0 (MVMC).

Новые возможности Virtual Machine Converter 2.0:

• Конверсия виртуальных дисков VMware в формат VHD с возможностью последующей загрузки на платформу Windows Azure.
• Нативная поддержка Windows PowerShell, что позволяет разрабатывать различные сценарии по автоматизации задач миграции на платформу Microsoft. На интерфейс PowerShell в MVMC 2.0 был заменен старый интерфейс командной строки MVMC 1.0.
• Поддержка конверсии виртуальных машин Linux с платформы VMware на хосты Hyper-V.
  
• Поддержка виртуальных машин, которые находятся в статусе "офлайн".
• Поддержка нового формата дисков VHDX при конверсии и миграции ВМ на платформы Windows Server 2012 R2 и Windows Server 2012 под управлением Hyper-V.
• Поддержка миграции ВМ на платформах VMware vSphere 5.5, VMware vSphere 5.1 и VMware vSphere 4.1 в среду Hyper-V.
• Поддержка гостевых ОС Windows Server 2012 R2, Windows Server 2012 и Windows 8, которые можно указывать как исходные при конверсии.

Механика работы утилиты Virtual Machine Converter проста - на платформе vSphere делается снапшот виртуальной машины, далее у нее удаляются VMware Tools, потом она выключается, ее диски преобразовываются и копируются на платформу Hyper-V, после чего происходит откат исходной виртуальной машины к начальному состоянию, которое было до снятия снапшота.

При конверсии офлайновой машины VMware Tools не удаляются, вместо этого отключаются сервисы и драйверы, связанные с VMware. Для гостевых ОС Linux удаления VMware Tools не происходит вовсе, поэтому делать это нужно вручную до конверсии.

Скачать Microsoft Virtual Machine Converter 2.0 вместе с документацией можно по этой ссылке.

В прошлой статье мы рассказали об анонсированных новых возможностях комплекта продуктов VMware Horizon 6, а сегодня мы рассмотрим их лицензирование.

Итак, в новой редакции линейки продуктов для управления ПК предприятия будет 3 издания:

• VMware Horizon View Standard - это традиционное решение для виртуализации настольных ПК предприятия VMware View, к которому добавляем решение для виртуализации ПК VMware ThinApp и составляющие платформы виртуализации - VMware vSphere и vCenter.
• VMware Horizon Advanced - это уже полноценное управление физической и виртуальной инфраструктурой ПК предприятия. Здесь добавляется средство по федерации приложений и рабочих сред Unified Workspace, возможности кластеров хранилищ Virtual SAN, а также средства управления образами физических ПК VMware Mirage.
• VMware Horizon Enterprise - ко всем прочим преимуществам добавляется еще решение VMware vCenter Operations for View 6, обеспечивающее автоматизацию управления и мониторинга инфраструктуры виртуальных ПК (мы писали об этом тут), кроме того в состав включается плагин для оркестрации операций (автоматизации с помощью сценариев) - vCO Plugin for VMware Horizon 6.

Также на картинке мы видим американские цены на лицензии. В России эти цены, само собой, будут существенно выше. Обратите внимание, что VMware View лицензируется только на одновременные подключения пользователей, а вот издания Horizon Advanced и Horizon Enterprise уже можно покупать и как именованные лицензии, что серьезно дешевле.

Так что если все пользователи у вас работают одновременно, лучше купить лицензию на Horizon Advanced - вы получите больше продуктов по цене обычного VMware View.

Кроме всего прочего появляется интересный момент в лицензии VMware vSphere Desktop - теперь она "отделилась" от решения VMware Horizon и доступна не только в его составе, но и отдельно по цене $50 (американская цена) за одновременное подключение пользователя. Ее можно использовать для случаев, когда пользователи используют виртуальные серверные системы (терминальные серверы) или виртуальные ПК для доступа к своим приложениям, при этом не покупают VMware Horizon.

Вкратце это все. Больше информации будет доступно ближе к релизу VMware Horizon 6, который состоится во второй половине этого года.

На днях ИТ-сообщество переполошилось из-за очень неприятного факта - уязвимости OpenSSL HeartBleed, которая была обнаружена в версии защищенного протокола OpenSSL 1.0.1 и 1.0.2-beta. Уязвимость получилась из-за того, что отсутствует необходимая проверка границ в одной из процедур расширения Heartbeat (RFC6520) для протокола TLS/DTLS.

Это позволяет злоумышленнику получить доступ к оперативной памяти сервера, где хранятся, в том числе, сами секретные ключи, имена и пароли пользователей, а также много чего еще. После того, как нехороший товарищ получил, что хотел, обнаружить факт его проникновения в систему невозможно. За один такт можно получить сегмент в 64 КБ памяти, но делать это такими кусочками можно сколь угодно долго, постоянно обновляя соединение.

Как пишет Хабр, 1 января 2012 года, Robin Seggelmann отправил, а steve проверил commit, который добавлял HeartBeat в OpenSSL. Именно этот коммит и привнес уязвимость, которую назвали Heartbleed. То есть, пару лет любой желающий мог вылавливать данные из памяти где-то 2/3 всех защищенных серверов мира. Эта версия OpenSSL используется в веб-серверах Nginx и Apache, в почтовых серверах, IM-системах, VPN, а также еще очень-очень много где. Сертификаты скомпрометированы, логины/пароли, возможно, утекли к посторонним людям. Кошмар, бардак, ядерная война.

Например, уязвимость есть вот в этих Linux-дистрибутивах:

• Debian Wheezy (стабильная), OpenSSL 1.0.1e-2+deb7u4)
• Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11)
• CentOS 6.5, OpenSSL 1.0.1e-15)
• Fedora 18, OpenSSL 1.0.1e-4
• OpenBSD 5.3 (OpenSSL 1.0.1c) и 5.4 (OpenSSL 1.0.1c)
• FreeBSD 8.4 (OpenSSL 1.0.1e) и 9.1 (OpenSSL 1.0.1c)
• NetBSD 5.0.2 (OpenSSL 1.0.1e)
• OpenSUSE 12.2 (OpenSSL 1.0.1c)

Ну и, конечно же, серверы VMware ESXi 5.5 (build 1331820) и ESXi 5.5 Update 1 (build 1623387) также имеют эту уязвимость. Проверить это просто - выполняем команду:

# vmware -vl

VMware ESXi 5.5.0 build-1331820
VMware ESXi 5.5.0 GA

# openssl version -a

OpenSSL 1.0.1e 11 Feb 2013
built on: Tue Feb 26 16:34:26 PST 2013

Видим, что здесь версия 1.0.1e, которая подвержена уязвимости.

А вот для пользователей VMware ESXi 5.1 бонус - уязвимости тут нет, так как используется другой бранч OpenSSL (0.9.8y):

# vmware -vl

VMware ESXi 5.1.0 build-1612806
VMware ESXi 5.1.0 Update 2

# openssl version -a

OpenSSL 0.9.8y 5 Feb 2013
built on: Wed Mar 20 20:44:08 PDT 2013

Есть даже вот такая табличка с VMware Communities, где показано, какие компоненты и каких версий подвержены уязвимости (выделенные цветом - подвержены):

Фикса бага пока нет - но он ожидается в ближайшие дни (возможно, на момент прочтения вами этой заметки он уже выйдет). За развитием ситуации можно также следить тут.

Подробное описание уязвимости можно прочитать на специальном сайте: http://heartbleed.com/.

Проверить свой публичный сайт на наличие уязвимой версии протокола можно вот тут: http://filippo.io/Heartbleed/.

Многие администраторы VMware vSphere знают, что еще в версии Veeam Backup and Replication 6.5 появилось средство Veeam Explorer for SAN, которое поддерживает гранулярное (то есть до уровня отдельных объектов гостевой ОС) восстановление виртуальных машин напрямую из снапшотов, сделанных устройствами хранения. До настоящего времени это решение поддерживало только хранилища HP StoreVirtual VSA и HP LeftHand (а также была добавлена поддержка StoreServ, т.е. 3PAR). Эта технология изначально была разработана Veeam совместно с HP и поддерживала все функции Veeam: Instant VM Recovery, Instant File-Level Recovery и Explorer for Exchange item recovery.

Теперь же, совсем недавно, компания Veeam Software объявила о партнерстве с NetApp - одним из лидеров в области производства систем хранения данных. Теперь Veeam Backup & Replication 8, который будет следующим мажорным релизом ведущего продукта для резервного копирования и репликации ВМ, сможет восстанавливать виртуальные машины напрямую из снапшотов NetApp:

Это уже вторая фича, заявленная к выпуску в восьмой версии Veeam B&R, первой, напомним, было средство восстановления объектов каталога Active Directory из резервных копий виртуальных машин - Veeam Explorer for Active Directory.

Основные возможности Veeam Explorer for SAN при работе с массивами NetApp:

• Fast backups: возможность резервного копирования виртуальных машин из снапшотов хранилищ, сделанных самим NetApp, что работает до 20 раз быстрее.
• Quick recovery: возможность восстановления машин или их отдельных объектов (документы Exchange, файлы гостевых ОС и т.п.) из объектов хранилищ, сделанных средствами технологий NetApp Snapshot, SnapMirror и SnapVault.
• Improved protection: возможность создания снапшотов или удаленных резервных копий инфраструктуры средствами хранилищ NetApp (например, на DR-площадке).

Пример помещения второго бэкапа в удаленное волт-хранилище в целях обеспечения катастрофоустойчивости инфраструктуры:

Интеграция Veeam Backup & Replication 8 и массивов NetApp ожидается во второй половине 2014 года. Пока же можно посмотреть вебинар "How Veeam and NetApp deliver Advanced Data  Protection for the Modern Data Center", который пройдет 17 апреля.

Более подробно об интеграции Veeam и NetApp можно почитать на этой странице.

Интересную особенность тут обнаружил один из читателей Дукана Эппинга: оказывается в VMware vSphere 5.5 Update 1 при перезапуске/выключении хоста VMware ESXi через консоль DCUI рестарта его виртуальных машин посредством механизма VMware HA не происходит.

Ну то есть, если выключение ESXi делать по клавише <F12> в консоли сервера:

Действительно, в этом случае в логе FDM можно увидеть вот такую запись:

2014-04-04T11:41:54.882Z [688C2B70 info 'Invt' opID=SWI-24c018b] [VmStateChange::SavePowerChange] 
vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx 
curPwrState=unknown curPowerOnCount=0 newPwrState=powered off clnPwrOff=true hostReporting=host-113

Это означает, что VMware vSphere считает, что виртуальные машины были выключены корректно (администратором/хостом), а значит их перезапуск механизмом VMware HA не требуется (параметр clnPwrOff=true).

Совсем другая картина, если мы делаем ребут или выключение VMware ESXi из VMware vSphere Client или vSphere Web Client:

В этом случае в логе FDM мы обнаружим что-то вроде такого:

2014-04-04T12:12:06.515Z [68040B70 info 'Invt' opID=SWI-1aad525b] [VmStateChange::SavePowerChange] 
vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx 
curPwrState=unknown curPowerOnCount=0 newPwrState=powered on clnPwrOff=false hostReporting=host-113

Здесь уже мы видим, что clnPwrOff=false, а значит vSphere полагает, что что-то пошло не так и VMware HA перезапустит виртуальные машины "отказавшего" хоста.

Это поведение актуально для VMware vSphere 5.5 Update 1, но пользователи в комментариях к статье Дункана отмечают, что подобное поведение наблюдается и для vSphere 5.0. Поэтому будет не лишним знать об этом всем тем, кто после настройки отказоустойчивого кластера VMware HA тестирует его работоспособность путем перезагрузки хостов ESXi.

Не все администраторы VMware vSphere знают о том, что в версии vSphere 5.5, компания VMware сделала специальную настройку для виртуальных машин - Latency Sensitivity. Она позволяет снизить издержки на виртуализацию для виртуальной машины в случае, когда требуется ее производительность близкая к нативной (то есть почти без потерь на нужды слоя виртуализации).

Найти ее можно в vSphere Web Client, если выбрать нужную ВМ, перейти на вкладку Manage, далее выбрать Settings->VM Options и в разделе Advanced Settings перейти на опцию Latency Sensitivity:

Там можно выбрать значения Low, High, Medium и Normal, однако значения Medium и Normal в vSphere 5.5 являются экспериментальными, поэтому пока можно использовать только Low (по умолчанию) и High (режим высокой производительности для чувствительных нагрузок).

Детально о том, что конкретно делает этот режим, можно почитать в документе "Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5", мы же здесь приведем основные моменты.

Итак, если вы ставите Latency Sensivity для виртуальной машины в значение High, происходит следующее:

Виртуальная машина получает эксклюзивный доступ к физическим ресурсам хоста

• Планировщик CPU хоста ESXi определяет возможность того, может ли быть предоставлен эксклюзивный доступ виртуального процессора vCPU к физическому процессору (ядру) сервера pCPU, учитывая реальное состояние процессора (нагруженность, over-commit и прочее). При возможности происходит резервирование pCPU для виртуального процессора на 100%. В этом случае никакие другие vCPU и трэды не могут быть исполнены на этом pCPU (включая VMkernel I/O threads).
• Возможность latency-sensitivity требует от пользователя установки резервирования памяти (Memory Reservation), чтобы выделенная виртуальной машине память не была ненароком отдана другой машине средствами Memory Ballooning. Это позволит дать гарантию, что машина всегда будет иметь в своем распоряжении четко выделенный сегмент физической оперативной памяти хоста ESXi, даже в случае недостатка ресурсов на хосте.

Обход слоя виртуализации

• Как только машина получила эксклюзивный доступ к pCPU, ее виртуальный процессор может напрямую взаимодействовать с его ресурсами в обход планировщика VMkernel. Это ликвидирует затраты на переключение между VMkernel и монитором виртуальных машин (VMM), однако переключения между исполнением кода гостевой ОС и VMM по-прежнему остаются (но это делается очень быстро за счет технологий аппаратной виртуализации, которые есть сейчас в любом процессоре).

Тюнинг механизмов виртуализации на хосте

• Когда в качестве виртуального сетевого адаптера (VMNIC) виртуальной машины используется устройство VMXNET3, то функция Interrupt coalescing и поддержка LRO отключаются, чтобы уменьшить время отклика и джиттер. Если виртуальной машине не нужны такие функции, как vMotion, NetIOC и Fault tolerance, то можно и нужно использовать механизмы проброса сетевого устройства напрямую в виртуальную машину (pass-through) через механизм Single-root I/O virtualization (SR-IOV). Поддержка этого механизма появилась еще в VMware vSphere 5.1, но была существенно доработана в версии 5.5.

Вкратце это все, но больше новых подробностей о требовательных ко времени отклика виртуальных машинах можно почерпнуть из приведенного выше документа.

Некоторые администраторы (которые, например, используют контроллер домена как единую точку руления инфрастуктурой) были удивлены, что с выходом VMware vSphere 5.5 толстый C#-клиент vSphere Client отказывается устанавливаться на контроллере Active Directory. При попытке такой установки будет показана ошибка:

vSphere Client requires Windows XP SP2 or later. 
vSphere Client cannot be installed on a Domain Controller.

Все это от того, что у Microsoft есть стандарт о том, что на контроллере домена не должно быть установлено никакого дополнительного ПО, не относящегося к функциям AD. И VMware вынуждена ему подчиняться. Хотя это и не логично - не всем нужна отдельная машина в небольшой инфраструктуре чисто под управление VMware vSphere.

Ограничение обходится просто. Запускаем установщик клиента с параметром обхода проверок:

VMware-viclient.exe /v "SKIP_OS_CHECKS=1"

Второй вариант - использовать на контроллере домена виртуализованный с помощью ThinApp толстый клиент (ThinApped vSphere Client), о котором мы уже писали тут.

Но его придется создать самостоятельно - актуальная версия поддерживаемой сейчас платформы - vSphere 5.0. Хотя есть кастомные версии и для 5.1.

Некоторым администраторам VMware vSphere в крупных инфраструктурах иногда приходится сталкиваться с задачей по переносу распределенного виртуального коммутатора VMware vSphere Distributed Switch в другую инфраструктуру (миграция, восстановление после сбоя и т.п.). При этом многие знают, как перенести vCenter и SSO, но не знают как быть с этим коммутатором.

Специально для этого компания VMware сделала обучающее видео по процессу резервного копирования и восстановления конфигурации VMware vSphere Distributed Switch:

Но это еще не все. Для тех, кто хочет пройти эти процессы самостоятельно на практике, VMware сделала пошаговое руководство в формате walkthrough (о них мы уже писали тут и тут) - то есть набора экранов, где нужно самостоятельно кликать на элементы в vSphere Web Client:

Как многие знают, в VMware vSphere 5.5 был полностью переписан движок сервисов аутентификации Single-Sign-On (SSO), так как раньше VMware использовала стороннее решение. Теперь же нет старой базы RSA, а контроллеры доменов Active Directory не нужно указывать напрямую. Механизм аутентификации стал проще, но при этом эффективнее.

Итак, например, у вас такая задача - есть домен, в который вы заводите серверы VMware ESXi и vCenter, и администраторы которого будут рулить виртуальной инфраструктурой. Но у вас есть и второй трастовый домен, пользователей которого вы бы также хотели наделять полномочиями по управлению своей частью инфраструктуры. Тут надо отметить, что полноценная поддержка односторонних и двусторонних AD-трастов появилась только в vSphere 5.5, поэтому в более ранних версиях платформы сделать этого по-нормальному не получится.

Итак, как мы помним, завести серверы VMware ESXi в домен AD можно в раздеде Configuration-> Authentication Services

Тут можно добавить основной домен, но в строчке Trusted Domain Controllers мы увидим пустоту, так как настраивать это нужно не через "толстый" vSphere Client, который скоро перестанет поддерживаться, а через "тонкий" vSphere Web Client, в котором возможности добавления источников аутентификации для сервера SSO весьма обширны.

Итак:

• Открываем Sphere Web Client по ссылке https://<адрес сервера vCenter>:9443/vsphere-client
• Заходим обязательно как administrator@vsphere.local. Именно под этим пользователем - обычный админ не прокатит - раздел SSO будет скрыт.
• Идем в раздел Administration > Single Sign-On > Configuration

Если этого раздела в vSphere Web Client вы не видите, значит вы зашли не под administrator@vsphere.local.

Далее идем в раздел Identity Sources и там нажимаем "+":

Добавляем новый источник:

Добавляем источник именно как "Active Directory as a LDAP Server", так как основной источник Active Directory (первый вариант) может быть добавлен только один.

Вот пример заполнения данных по домену:

Тут не заполнены только обязательные поля "Base DN for users" и "Base DN for groups". Если вы хотите искать пользователей во всем каталоге домена, то укажите в обоих этих полях просто подобное значение (из примера):

DC=virten,DC=local

Далее нужно протестировать соединение (Test Connection).

После того, как новый домен будет добавлен как Identity Source, его можно будет увидеть при добавлении любого разрешения на вкладке Permissions:

Вот так все и просто. Добавляете пользователя и даете ему права на различные объекты виртуальной инфраструктуры VMware vSphere.

В последнее время мы много писали о решении VMware Virtual SAN (например, тут, тут и тут), которое, казалось бы, нахваливали со всех сторон. Само по себе решение весьма неплохое, но в этом посте мы положим половничек дегтя в выглядящую распрекрасно бочку меда VSAN.

Итак, VMware Virtual SAN поставляется в трех вариантах:

• VMware VSAN с лицензией на процессоры хост-серверов VMware ESXi.
• VSAN with Data Protection - вместе с лицензией на средство резервного копирования VMware vSphere Data Protection.
• VSAN for Desktop - для размещения виртуальных ПК в инфраструктуре VMware Horizon View. Лицензируется на пользователя (именованного или по одновременным подключениям), вне зависимости от объема виртуальных ПК и используемых процессоров хостов.

Американская стоимость этих вариантов такова:

Как мы видим, если наш сервер VMware ESXi двухпроцессорный, то за лицензию VSAN на один сервер придется заплатить почти $5K. Что превышает стоимость некоторых неплохо упакованных серверов. Ах, да - мы забыли поддержку, которую обязательно приобретать с большинством продуктов VMware (без нее купить нельзя).

Давайте же взглянем на российский ценник:

• VMware Virtual SAN 5 for 1 processor (ST-VSAN-C) = $2 744,50
• Basic Support/Subscription for VMware Virtual SAN 5 for 1 processor (ST-VSAN-G-SSS-C) = $ 576,40 * 1,18 (НДС) = $680,15

Итого = $3424,65 * 2 (два процессора) = $6849,30

С учетом сегодняшнего курса доллара, который скачет как волшебный кролик, получается весьма (не)приличная сумма за программку для создания кластеров хранилищ.

Ну вы помните, да, что еще вообще-то нужно покупать VMware vSphere? Давайте взглянем, сколько сейчас стоит лицензия VMware vSphere Enterprise Plus на рассматриваемый нами сервер:

• VMware vSphere 5 Enterprise Plus for 1 processor (VS5-ENT-PL-C) = $4 543,50
• Basic Support/Subscription for VMware vSphere 5 Enterprise Plus for 1 processor for 1 year (VS5-ENT-PL-G-SSS-C) = $954,20 * 1,18 (НДС) = $1125,95

Итак, стоимость VMware vSphere на 1 сервер составляет: $5669,45 * 2 (два процессора) = $11 338,90.

Ну что ж, мы близки к катарсису. Сложим стоимость лицензий VMware vSphere и Virtual SAN для одного двухпроцессорного сервера:

$6849,30 + $11 338,90 = $ 18 188,20

Восемнадцать штук баксов за софт на сервере! Может это и нормально, кто знает. Этот пост не о том, как это дорого, а о том, во сколько это вам обойдется. Так-то.

Ну и для тех, кто готов идти дальше несмотря ни на что, обновились демки решения Virtual SAN на сайте проекта VMware Product Walkthrough Demos:

Как многие уже слышали, совсем недавно вышла первая версия продукта VMware VSAN, который был выпущен одновременно с релизом обновленной платформы VMware vSphere 5.5 Update 1. Многие уже принялись тестировать это решение, которое (что похвально) теперь работает производительнее своей же бета-версии и в то же время линейно масштабируется по количеству узлов ESXi с точки зрения производительности...

Мы много писали про функции ускорения 3D-графики в решении для виртуализации настольных ПК VMware View (например, тут и тут). Это режимы vSGA и vDGA, поддержка которых появилась еще в версии VMware View 5.2, но полноценно была добавлена только в версии VMware View 5.3. Ниже мы расскажем о некоторых аспектах использования этих режимов, опираясь на полезнейший документ "Graphics Acceleration in VMware Horizon View Virtual Desktops", где помимо теории даны и практические советы по настройке инфраструктуры для работы виртуальных машин в режимах vSGA и vDGA.

Итак, начнем с определений:

• Soft 3D - рендеринг 3D-картинки без использования адаптера на основе программных техник с использованием памяти сервера.
• vDGA - выделение отдельного графического адаптера (GPU) одной виртуальной машине.
• vSGA - использование общего графического адаптера несколькими виртуальными машинами.

Сразу отметим, что забота о поддержке режимов vDGA и vSGA лежит на плечах вендоров графических адаптеров. Пока этим в достаточной степени прославилась только компания NVIDIA.

Ниже рассмотрим картинку, на которой представлены варианты использования графических режимов для различных типов задач, которые предполагаются для работников, использующих виртуальные ПК:

Условно тут можно выделить 4 типа пользователей, касательно графически интенсивных нагрузок:

• Task Worker - обычный сотрудник (например, программист или менеджер по продажам), который не использует специальных графических программ и тяжелых нагрузок. Для него вполне подойдет софтверный рендер
• Knowledge Worker - этот человек имеет в своем распоряжении некоторое программное обеспечение, трубующее работы с графической подсистемой (например, иногда запускает Adobe Photoshop или смотрит видеоролики). Некоторым (в зависимости от частоты использования этих средств) вполне подойдет софтверный рендер, но кому-то будет нужная машина с поддержкой аппаратного рендеринга (но, скорее всего, в режиме vSGA).
• Desktop Power User - этот человек уже интенсивно работает с графическими пакетами, возможно, на нескольких мониторах. При этом используются графические библиотеки OpenGL или DirectX (но не самых последних версий).
• Workstation User - этот пользователь профессионально использует виртуальный десктоп для графически-интенсивных нагрузок (например, CAD-приложения или приложения для обработки и кодирования видео). Отличительная черта таких пользователей - профессиональное использование основного инструмента, требовательного к графике.

Соответственно, на диаграмме видно, когда и какой режим работы с графикой нужно использовать, в зависимости от категории пользователей. Практически это выглядит следующим образом: например, обычные офисные приложения вполне будут работать в режиме vSGA:

А вот некоторые пользователи тяжелых графических программ (например, Adobe Premiere) будут чувствовать себя комфортно только в режиме vDGA:

Режим vSGA

Идем дальше. Режим vSGA - это самый простой и эффективный способ использовать аппаратное ускорение для 3D-графики в виртуальных машинах. Он ограничивает системного администратора только объемом видеопамяти, которой, однако, у адаптера тоже не бесконечно много. На март этого года для режима vSGA поддерживаются следующие адаптеры:

• Nvidia GRID K1
• NvidiaGRID K2
• Nvidia Quadro 4000
• Nvidia Quadro 5000
• Nvidia Quadro 6000
• Nvidia Tesla M2070Q

В режиме vSGA есть три варианта использования:

• Automatic - аппаратное ускорение будет использовано только в случае доступного и подходящего GPU на хосте, где эта ВМ запущена. Если такого нет - то используется софтверный рендер. Когда машина переместится на подходящий хост - включится режим vSGA.
• Software only - всегда используется софтверный рендер (даже если есть свободные ресурсы GPU). Эта конфигурация работает на любом хосте.
• Hardware only - обязательное использование аппаратного ускорения. В этом случае проверяются условия при старте или миграции виртуальной машины на другой хост. Если они не выполняются - этого не происходит.
• Disabled - 3D-рендеринг не используется вовсе.

В плане драйвера гостевой ОС используется стандартный драйвер VMware SVGA 3D graphics. Но на сам ESXi нужно поставить специальные VIB-пакеты, которые будут обеспечивать работу виртуальных машин в режиме vSGA. Например, драйвер для ESXi 5.1 находится тут, а для ESXi 5.5 - тут.

Режим vDGA

Этот режим предназначен для случая, когда отдельный GPU нужно целиком и полностью отдать виртуальной машине. Этот режим основан на технологии VMware vSphere DirectPath I/O (то есть, прямой проброс устройств). Соответственно, здесь важно количество GPU на хосте VMware ESXi, которое и определяет максимальное количество запущенных виртуальных машин с поддержкой vDGA. Ну а максимальное число таких GPU на сервере определяется числом слотов PCIe x16 (нужно множить на число GPU у одного адаптера).

Например, на сервере Dell R720 может быть две карты NVIDIA GRID K2, каждая из которых имеет 2 GPU. Таким образом, максимальное количество виртуальных машин с поддержкой vDGA может быть четыре штуки.

В случае с vDGA используется драйвер от вендора, который и занимается работой с нижележащим оборудованием и видеокартой. На данный момент режим vDGA поддерживается для следующих графических адаптеров:

• Nvidia GRID K1
• Nvidia GRID K2
• Nvidia Quadro K2000
• Nvidia Quadro K4000
• Nvidia Quadro K5000
• Nvidia Quadro K6000
• Nvidia Quadro 1000M
• Nvidia Quadro 2000
• Nvidia Quadro 3000M
• Nvidia Quadro 4000
• Nvidia Quadro 5000
• Nvidia Quadro 6000
• Nvidia Tesla M2070Q

Кстати, при использовании таких адаптеров нужно учитывать электропитание серверов, так как, например, NVIDIA Quadro 6000 GPU использует до 200 Ватт мощности.

Если объединить специфику режимов софтверного рендера, vSGA и vDGA получится вот такая табличка:

Тут надо отметить, что как для vSGA, так и для vDGA режимов поддерживаются только гостевые ОС Windows 7 (для vSGA - x86 и x64, для vDGA - только x64).

Текущее выделение графических адаптеров и режим их работы можно проверить следующей командой на сервере VMware ESXi:

# gpuvm

Вывод будет примерно таким:

# gpuvm
Xserver unix:0, GPU maximum memory 2076672KB
pid 118561, VM “Test-VM-001”, reserved 131072KB of GPU memory
pid 664081, VM “Test-VM-002”, reserved 261120KB of GPU memory
GPU memory left 1684480KB

За дальнейшими подробностями можно проследовать в документ "Graphics Acceleration in VMware Horizon View Virtual Desktops".

Давно что-то не было новостей в сфере обновления инструментов для автоматизации операций в инфраструктуре VMware vSphere. Но вот они и пришли - сразу же после выхода VMware vSphere 5.5 и технологии Virtua SAN компания VMware выпустила обновление PowerCLI 5.5 R2.

Напомним, что PowerCLI является надстройкой над Microsoft PowerShell, которая позволяет администраторам просто управлять компонентами виртуальной инфраструктуры через командлеты:

Эта версия PowerCLI действительно принесла много нового, а именно:

• Возможность управления решением vCenter Site Recovery Manager через публичный API.
• Возможность создания/удаления тэгов и категорий тэгов.
• Получение статуса и настройка режима Enhanced vMotion Compatibility (EVC) для кластеров.
• Управление политиками безопасности для обычных виртуальных коммутаторов (vSwitch) и их групп портов.
• Поддержка Windows PowerShell 4.0.
• Поддержка серверов vSphere с настроенным IPv6.
• Указание приоритета миграции ВМ (VMotionPriority для командлета Move-VM).
• Возможность использования объекта Hard Disk как RelatedObject в методе Get-Datastore.
• Командлет Get-Datastore позволяет фильтровать вывод по кластерам.
• Командлеты Get-Stat и Get-StatType теперь работают со всеми типами, что позволяет собирать больше статистической информации.
• Добавлена поддержка сетевых адаптеров e1000e.
• Возможность указания всех значений в параметре DiskStorageFormat при клонировании виртуальной машины.
• Поддержка 64-битных ОС для методов New-OSCustomizationSpec и Set-OSCustomizationSpec.
• Свойство ToolsVersion объекта VMGuest показывает версию тулзов как строку.
• Возможность использования объекта virtual portgroup как RelatedObject в методах Get-VirtualSwitch и Get-DVSwitch.
• Получение списка ВМ рассортированного по виртуальным коммутаторам.
• Различные исправления ошибок и улучшения производительности командлетов, которые можно посмотреть в логе изменений.

Вот какие штуки теперь можно использовать для решения VMware SRM через PowerCLI:

• Protect a Virtual Machine - настройка репликации ВМ на удаленную площадку.
  
• Connect-SrmServer - соединение с сервером vCenter Site Recovery Manager (SRM).
• Create a Report of the Virtual Machines Associated with All Protection Groups - простенький отчет о виртуальных машинах и протекш-группах, в которые они входят.
• Create a Report of the Protected Virtual Machines - простенький отчет о всех защищенных SRM виртуальных машинах.

Кроме vSphere PowerCLI 5.5 R2 обновился также и vCloud Director PowerCLI R2, который можно опционально установить при развертывании этого средства.

Больше информации о новых возможностях интерфейса PowerCLI можно получить из документа "VMware vSphere PowerCLI 5.5 Release 2 User’s Guide". А о самих командлетах можно почитать в документе "VMware vSphere PowerCLI 5.5 Release 2 Cmdlet Reference".

Скачать PowerCLI 5.5 R2 можно бесплатно по этой ссылке.

Недавно мы писали о том, что компания VMware планирует выпуск решения для создания кластеров хранилищ на базе локальных дисков серверов - VMware Virtual SAN. И вот это случилось - вышла первая версия VMware Virtual SAN 1.0 и обновление VMware vSphere 5.5 Update 1, в котором есть поддержка VSAN (кстати, апгрейд с бета-версий VSAN на релизную не поддерживается). Для ESXi и vCenter апдейт с прошлой версии является кумулятивным, поэтому нет нужды накатывать предыдущие патчи для 5.5.

Помимо поддержки VMware VSAN, в платформе VMware vSphere 5.5 Update 1 добавились следующие функции:

• Плагин клиента vCloud Hybrid Service теперь доступен в vSphere Web Client.
• vCenter Server теперь полностью поддерживается на платформе Windows Server 2012 R2.
• Множественные исправления ошибок.

Надо отметить, что для поддержки VMware Virtual SAN обновилась не только платформа VMware vSphere, но и решение для виртуализации настольных ПК VMware Horizon View, которое теперь поддерживает размещение десктопов на хранилищах VSAN. Поэтому приведем ниже основные ссылки на обновившиеся компоненты:

• vCenter Server Update 1 download (+ release notes)
• ESXi 5.5 Update 1 download (+ release notes)
• Horizon View 5.3.1 download (VSAN release) (+ release notes)
• Horizon Workspace 1.8 (+ release notes)

Кстати, для тех, кто хочет узнать о том, как начать использовать VSAN с VMware Horizon View, есть вот такая KB 2073795.

В составе vSphere обновились также следующие компоненты до новых версий:

• vSphere Replication 5.5.1 (скачать)
• vSphere Data Protection 5.5.6 (скачать)
• VMware vCenter Orchestrator appliance 5.5.1 (скачать)

Но это еще не все. Обновились также и другие продукты VMware, чтобы обеспечить поддержку VSAN:

• VMware vCloud Director 5.5.1 (скачать)
• VMware vCenter Operations Manager Advanced 5.8.1 (скачать)
• VMware vCenter Hyperic 5.8.1 Server (и agent) (скачать)
• VMware vCenter Site recovery manager 5.5.1 (скачать)
• VMware vCloud Application Director 6.0.1 (скачать)

Централизованно все обновленные компоненты решений VMware можно найти по этой ссылке.

А вот в какой последовательности стоит обновлять эти компоненты, если у вас много продуктов VMware, и вы хотите внедрять VSAN:

* Если вы используете Cisco Nexus 1000V, см. KB 2057795
** Если вы используете vSphere Storage Appliance, убедитесь, что vCenter Server был обновлен минимум до версии vSphere 5.1 Update 1, чтобы он поддерживал vSphere Storage Appliance 5.5.

Напомним также все наши посты о решении VMware Virtual SAN:

• 10 марта выходит VMware Virtual SAN (VSAN) - основные особенности
• Калькулятор для расчета необходимой дисковой емкости под кластер VMware Virtual SAN (VSAN)
• Как кластер VMware Virtual SAN (VSAN) обслуживает запросы на чтение блоков
• Как ведет себя кластер VMware Virtual SAN (VSAN) в случае сбоев дисков или хоста VMware vSphere / ESXi
• Сайзинг кластеров хранилищ VMware VSAN в VMware vSphere и их отказоустойчивость
• Обновление VMware Virtual SAN Beta - и сравнение производительности с каким-то Flash-массивом
• Производительность кластера хранилищ VMware VSAN для виртуальных ПК VMware View при масштабировании
• Новый документ: "What’s New in VMware Virtual SAN (VSAN)"
• Чем отличаются VMware VSA и VSAN - сравнение

Ну и последнее, но не менее важное. Практически одновременно с релизом VSAN 1.0 компания VMware выпустила очень полезный документ "VMware VSAN Design and Sizing Guide", в котором приводятся различные рекомендации по построению инфраструктуры VSAN, а также выбору числа дисков, памяти и других параметров и количества хост-серверов VMware ESXi.

Также в документе приведены практические примеры по расчету необходимого числа хостов и дисковой емкости:

Документация по VMware VSAN доступна тут.

Мы постоянно рассказываем о новых стенсилах, иконках, шаблонах и диаграммах, которые позволяют вам документировать виртуальную инфраструктуру, когда вы создаете презентации и различные схемы (например, тут, тут и тут). На днях компания Veeam Software обновила свои бесплатные стенсилы для Visio, которые теперь доступны в двух вариантах - 3D и 2D.

Стенсилы 2D-формата выполнены в стиле Windows Metro и позволяют создавать схемы в простом "плоском" стиле:

Среди шаблонов Veeam вы сможете найти следующие объекты виртуальной инфраструктуры как VMware, так и Microsoft:

• Хосты ESXi и Hyper-V
• Виртуальные датацентры
• Серверы SC VMM
• Локальные и общие хранилища
• Логические тома LUN
• Виртуальные машины (в различных состояниях)
• Сетевые адаптеры (NICs)
• Виртуальные сети и многое другое

Скачать бесплатные стенсилы Veeam для VMware и Microsoft можно по этой ссылке.

Мы уже очень много писали про технологию VMware VSAN, которая позволяет создать кластер из локальных хранилищ хостов VMware ESXi (например, последнее - тут, тут и тут). На днях стало известно, что 10 марта состоится релиз этого решения, которое будет поставляться как дополнение к VMware vSphere, либо как предустановленное решение на брендовых серверах.

VSAN - один из самых серьезных и сложных продуктов VMware. В его тестировании приняло участие более 12 тысяч пользователей, и вот версия 1.0 уже почти готова.

Какие особенности будут у финальной версии VMware Virtual SAN:

• Технологию Virtua SAN будет поддерживать новый релиз платформы виртуализации vSphere 5.5 Update 1, который, очевидно, будет выпущен вместе с VSAN. Также будет поддерживаться и решение VMware Horizon View.
• Апгрейд бета-версий VSAN на релизную версию поддерживаться не будет.
• Стоимость и комплектация изданий будут известны вместе с выходом продукта 10 марта.
• Обещают, что производительность кластера VSAN будет масштабироваться линейно по мере роста количества узлов в нем.
• В кластере хранилищ VSAN поддерживается до 32-х узлов. Минимально нужно 3 хоста ESXi.
• На одном узле поддерживается работа до 100 виртуальных машин. Всего, таким образом, получается до 3200 машин в кластере.
• Для работы кластера на каждом узле должны быть как SSD-диски (как минимум один), так и HDD-накопители. Если чего-то из этого нет - работать не будет.
• Максимально на одном узле поддерживается до 35 HDD-дисков и до 5 SSD-дисков (один SSD на 7 HDD, то есть каждые 7 дисков обязательно требуют твердотельный диск емкостью около 0.1 от совокупной емкости этих HDD).
• Суммарно поддерживаемая емкость кластера = 35 дисков * 32 хоста = 4.4 петабайта хранилища.
• Где можно использовать VSAN (например): для VDI-инфраструктуры, среднекритичные нагрузки (Tier 2/3) и DR-сценарии (хранилища резервной площадки).
• Минимальная скорость адаптера на хосте ESXi - 1 Гбит, но чтобы все работало надежно, очень рекомендуется строить сеть на адаптерах 10 Гбит. А все потому, что репликация идет синхронно.
• Дедупликации пока не будет.
• Производители оборудования, такие как Dell, HP и Cisco будут поддерживать VSAN и серверы "VSAN Ready". Вот тут можно посмотреть на список совместимого с VSAN оборудования. В день релиза станут доступными аж 13 готовых к VSAN конфигураций.
• Ввод-вывод на узле кластера разгоняли до 2-х миллионов IOPS (IOmeter 100% read, 4KB block size, а также 640K IOPS с профилем нагрузки 70/30 read/write и 4KB block size).
• Многие видели, что поддерживается совместная работа технологии VSAN с некоторыми решениями VMware, такими как vSphere Replication. Теперь также будет поддерживаться vSphere Data Protection for backups, vMotion, DRS, HA и многое другое.

Ну что ж, ждем с нетерпением выхода этой штуки, которая может оказаться весьма полезной многим.